Don't emit a leading boolean operator for the first enabled filter rule (fixes #76)

Problem

JavaScriptBuilder.appendFilterScript builds the filter as one boolean expression,
prefixing every enabled rule with its operator:

builder.append("function doFilter() { ... return (");
for (...) {
    String operator = "";
    if (rule.getOperator() == AND) operator = " && ";
    else if (rule.getOperator() == OR) operator = " || ";
    builder.append(operator + "(filterRule" + i + "() == true)");
}

The operator of the first term is emitted too. Normally the first rule's operator is
NONE/null, so nothing is prepended. But when the first step is disabled, the next
enabled rule carries the AND/OR it was given relative to the step above it, so the
expression starts with a dangling operator:

function doFilter() { ... return ( && (filterRule1() == true) || (filterRule2() == true)); }

That is invalid JavaScript, so the channel fails to deploy. Multiple users have hit this
in production.

Fix

Skip the operator for the first enabled rule — it has nothing to combine with:

boolean firstRule = true;
for (...) {
    String operator = "";
    if (!firstRule) {
        if (rule.getOperator() == AND) operator = " && ";
        else if (rule.getOperator() == OR) operator = " || ";
    }
    firstRule = false;
    builder.append(operator + "(filterRule" + i + "() == true)");
}

The channel now deploys and the disabled step does not execute, which is the expected
behavior described in the issue.

Tests

Added JavaScriptBuilderTest.testFilterDisabledFirstRuleNoLeadingOperator: a disabled
first step followed by an enabled AND rule must not produce a leading operator in
doFilter(). The test fails on main and passes with this change; the existing
JavaScriptBuilderTest cases are unchanged (7 tests, 0 failures).

A note on approach

The issue raised three possible directions: disallow saving this configuration, fix the
generated code, or reorder so the first enabled rule becomes the first. This PR takes the
second — fixing the generated code — as the least invasive change that produces the
issue's stated expected behavior. Happy to switch to validation-on-save or reordering if
you'd prefer one of those.